Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 1/csmp-v1-175.txt

Text File | 1992-12-31 | 44.7 KB | 1,096 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 04 Oct 92       Volume 1 : Issue 175

Today's Topics:

    Changing Command-Key for a menu item
    Using GetNextEvent or WaitNextEvent...
    Gestalt glue is redundant!



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Elliotte Rusty Harold)
Subject: Changing Command-Key for a menu item
Date: 15 Jul 92 12:31:17 GMT
Organization: New Jersey Institute of Technology


    Is there a means of changing not only the text of a menu item, but also
the Command-Key?  I'd like my application menu to toggle between Pause,
Command-Comma and Run, Command-R as appropriate.  Is there a toolbox call I'm
missing to do this?  Is there a hack to do this short of writing my own MDEF?
Is this a horrible violation of the user interface guidelines that will bring
down the wrath of the UI thought-police upon me?

Elliotte Rusty Harold        Department of Applied Mathematics
[e-mail]        New Jersey Institute of Technology
[e-mail]        Newark, NJ 07103

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 15 Jul 1992 13:19:11 GMT

[e-mail] (Elliotte Rusty Harold) writes:
>
>    Is there a means of changing not only the text of a menu item, but also
>the Command-Key?  I'd like my application menu to toggle between Pause,
>Command-Comma and Run, Command-R as appropriate.

I suggest two menu items, one of which is always dimmed.

It's incredible to me how an interface that prides itself on showing
everything to the user can _still_, in _1992_, have toggling menu items
that toggle the _name_.  What's wrong with a checkmark by a "Visible
Rulers" item?  Why does the item have to bounce between "Hide Rulers"
and "Show Rulers"?

The problem's especially distracting when combined with items that may
or may not be nouns.  When Ofoto says "Autostraighten On", does it mean:
    (a) Autostraightening is on;
    (b) If autostraightening were on, there'd be a checkmark here;
    (c) Select this item to turn autostraightening on?
Surely someone's noticed that people will select the item two or three
times in a row, watching it change, before they figure out what it does!

If it _does_ something, make it a verb:  Edit Macros.
If it _shows_ the state of something, make it a noun:  Fractional Widths.
If it _toggles_ between two states, make it a noun with a checkmark:
    >check< Visible Rulers.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Only one Amendment explains the reason for its existence; unfortunately,
 Congress is under no compulsion to follow reason.  "A well-regulated
 militia being necessary to the security of a free state..."

+++++++++++++++++++++++++++

From: [e-mail] (Max Pinton)
Organization: -> ESKIMO NORTH (206) For-Ever <-
Date: Tue, 21 Jul 1992 07:35:41 GMT

[e-mail] (Jamie R. McCarthy) writes:
: [e-mail] (Elliotte Rusty Harold) writes:
:
: It's incredible to me how an interface that prides itself on showing
: everything to the user can _still_, in _1992_, have toggling menu items
: that toggle the _name_.  What's wrong with a checkmark by a "Visible
: Rulers" item?  Why does the item have to bounce between "Hide Rulers"
: and "Show Rulers"?
:
: If it _does_ something, make it a verb:  Edit Macros.
: If it _shows_ the state of something, make it a noun:  Fractional Widths.
: If it _toggles_ between two states, make it a noun with a checkmark:
:     >check< Visible Rulers.

    Tog talks about this in _Tog on Interface_ ... Another problem with
rotating menu items is that the menu item indicates the opposite of the
current state; "Hide Rulers" is in the menu when the rulers are *not*
hidden.

    It's all pretty tacky to me.


---------------------------

From: [e-mail] (Dave Martin)
Subject: Using GetNextEvent or WaitNextEvent...
Date: 16 Jul 92 22:00:00 GMT
Organization: Geochemical & Environmental Research Group, Texas A&M University

What's the best way to implement a main loop which can get it's events
either from WaitNextEvent or GetNextEvent (if WNE isn't available on
that machine)? I've added the TrapAvailable stuff from IM VI for seeing
if the WNE trap is there, but am not sure of the best way to set up
the event checking (in THINK Pascal). My app needs to run on any Mac
and don't want to only use WNE in case it might cause it to not work
on particular Macs, but also don't want to just go with GNE.
I was thinking along the lines of a boolean (hasWNE) and doing an:
    IF (hasWNE AND WaitNextEvent(...)) OR
              (NOT(hasWNE) AND GetNextEvent(...)) THEN... (Main Loop)

[i.e. - if the WNE trap is there, and it returns an event; or, if WNE is
 not available and GNE returns an event...]

Is this a possible solution, or would this miss the point of WNE? Also,
would this still crash on a Mac which doesn't have the WNE trap?

 -                                                                     -
 - Dave Martin - Geochemical & Environmental Research Group, Texas A&M -
 - DAVE@GERGA[GERGO,GERGI].TAMU.EDU - [e-mail] - AOL:DBM -
 -                                                                     -

+++++++++++++++++++++++++++

From: [e-mail] (Tim Hammett)
Date: Fri, 17 Jul 1992 00:53:54 GMT
Organization: University of Auckland, New Zealand.

[e-mail] (Dave Martin) writes:
>What's the best way to implement a main loop which can get it's events
>either from WaitNextEvent or GetNextEvent (if WNE isn't available on
>that machine)? I've added the TrapAvailable stuff from IM VI for seeing

Here's what I did. (I say "did" because I'm not sure it's worth supporting
machines that don't have WaitNextEvent() any more. Even if you can get around
not having WaitNextEvent(), there are so many hairy problems involved
in supporting & testing on systems older than, say 6.02, that it probably
isn't worth the effort).

My approach was to have a dummy routine called "WNEEmulator" that takes the
same arguments as WaitNextEvent(). In my main event loop, I call the real
WaitNextEvent() if the trap exists, or the emulator if it doesn't.

Warning: Although this code works for me, it hasn't exactly been well
tested on a wide range of machines & system versions. Also note that it
was written before AppleEvents came along, so there might be additional
considerations relating to those (though I can't think of any at the moment).

/* Globals */

Boolean gHasWNE;            /* WaitNextEvent trap available */
Boolean gQuit;              /* Has the user chosen Quit? */
short gSysVersion;          /* Current system version (for avoiding System 4.x
                             * WNE bug on Mac II [TN177]) */
long gWNESleep = 50;        /* Time to sleep for in WaitNextEvent */
EventRecord gEvent;         /* Last event we got */
Boolean gInBackground;      /* Are we the foreground app? */
RgnHandle gCursorRgn;       /* Cursor tracking region for WaitNextEvent */


#ifdef applec /* Bung it in its own segment if this is MPW C */
    #pragma segment WNEEmulator
#endif

/* WaitNextEvent simulator - called if the WaitNextEvent() trap is not
 * available.
 */

Boolean WNEEmulator(short theMask,EventRecord *theEvent,unsigned long sleep,
    RgnHandle mouseRgn)
{
    static unsigned long lastMouseCheck; /* Only check mouse posn once per tick.
                                          * Needs to be static since routine
                                          * could be called more than once per
                                          * tick */
    unsigned long timeOut;
    Boolean gotEvent;


    timeOut = TickCount() + sleep;

    /* Mouse-moved events shouldn't be generated if mouseRgn is
     * the empty region */

    if( EmptyRgn(mouseRgn) )
        mouseRgn = nil;

    do {

        SystemTask();

        gotEvent = GetNextEvent(theMask,theEvent);

        if( ! gotEvent && mouseRgn != nil && lastMouseCheck < TickCount() ) {

            lastMouseCheck = TickCount();

            if( ! PtInRgn(theEvent->where,mouseRgn) ) {
                theEvent->what = osEvt;
                theEvent->message = 0xfa000000;
                gotEvent = true;
            }

        }

    } while( ! gotEvent && (TickCount() < timeOut) );

    return( gotEvent );
}

#ifdef applec
    #pragma segment Main
#endif


void EventLoop(void)
{
    Boolean gotEvent;

    do {

        if( gHasWNE ) {

            if( gSysVersion < 0x04ff && gInBackground && gWNESleep > 50 )
                gWNESleep = 50;     /* System 4.x bug on Mac II as per TN177 */

            gotEvent = WaitNextEvent(everyEvent,&gEvent,gWNESleep,gCursorRgn);

        }
        else
            gotEvent = WNEEmulator(everyEvent,&gEvent,gWNESleep,gCursorRgn);


        /* Ignore gotEvent for the moment, as we want to pass nullEvents
         * through as well */

        DoEvent( &gEvent );

    } while( ! gQuit );
}


- --
Tim Hammett, Botany Dept, Auckland University, New Zealand.
[e-mail]   Phone: [phone] x8365    FAX: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Dave Martin)
Date: 17 Jul 92 13:21:00 GMT
Organization: Geochemical & Environmental Research Group, Texas A&M University

In article <[e-mail]>, [e-mail] (Tim Hammett) writes...
>[e-mail] (Dave Martin) writes:
>>What's the best way to implement a main loop which can get it's events
>>either from WaitNextEvent or GetNextEvent (if WNE isn't available on
>>that machine)? I've added the TrapAvailable stuff from IM VI for seeing
>
>Here's what I did. (I say "did" because I'm not sure it's worth supporting
>machines that don't have WaitNextEvent() any more. Even if you can get around
>not having WaitNextEvent(), there are so many hairy problems involved
>in supporting & testing on systems older than, say 6.02, that it probably
>isn't worth the effort).

OK, maybe I'm assuming incorrectly, but what are the machine/system version
boundaries for whether WNE is available? I couldn't find any reference to
WNE in SpInside Mac 2.02 and the first reference I've seen is in IM VI,
which implies that it's a System 7 thing. Was it documented in a TN?
Primarily, I need my app to run in any environment which America Online
can run in, which I believe is Mac Plus and higher, 6.x and higher. Is
WNE present in all these cases?

 -                                                                     -
 - Dave Martin - Geochemical & Environmental Research Group, Texas A&M -
 - DAVE@GERGA[GERGO,GERGI].TAMU.EDU - [e-mail] - AOL:DBM -
 -                                                                     -

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Fri, 17 Jul 1992 15:18:18 GMT

In article <[e-mail]> [e-mail] (Dave Martin) writes:
>OK, maybe I'm assuming incorrectly, but what are the machine/system version
>boundaries for whether WNE is available?

The best way to find out if _WaitNextEvent (or any trap) is available is to
use something like the TrapAvailable code in IM-6.  (Of course the best best
way is to use Gestalt, but some things don't have selectors...).

_WaitNextEvent first appeared with the original Multifinder, which ran under
System version 4.2.  In this original version, _WaitNextEvent was _not_
present if Multifinder was turned off.  I believe that this OS version had a
collective name of System Tools 5.  When System 6 came out, things were
changed so that _WaitNextEvent was always present, whether or not Multifinder
was turned on.  If you don't want to bother with TrapAvailable (and you
really should), you can check for System 6 or newer.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Dave Martin)
Organization: Geochemical & Environmental Research Group, Texas A&M University
Date: Mon, 20 Jul 1992 19:01:00 GMT

In article <[e-mail]>, [e-mail] writes...
>The best way to find out if _WaitNextEvent (or any trap) is available is to
>use something like the TrapAvailable code in IM-6.  (Of course the best best
>way is to use Gestalt, but some things don't have selectors...).

That's exactly what I planned to do, since they provided the TrapAvailable
code right there.

>_WaitNextEvent first appeared with the original Multifinder, which ran under
>System version 4.2.  In this original version, _WaitNextEvent was _not_
>present if Multifinder was turned off.  I believe that this OS version had a
>collective name of System Tools 5.  When System 6 came out, things were
>changed so that _WaitNextEvent was always present, whether or not Multifinder
>was turned on.  If you don't want to bother with TrapAvailable (and you
>really should), you can check for System 6 or newer.

I guess I don't really need to bother with GNE, then. Since my app is meant
for AOL, and it (I believe) requires System 6.x or higher, then I'm probably
safe. What I did end up doing (thanks to the responses I got [well, except
for those who sent C code when I said "in THINK Pascal" ;] both here and in
email) was to use the TrapAvailable procedure to set a boolean, hasWNE. In
the main loop, I test hasWNE, if true, then I see if WNE has an event; if not,
I use GNE for the event. In both cases I set another boolean if there is an
event. I then do my CASE on the event record if hasEvent is true. It works,
even if it might not be the most efficient. I may go ahead and rewrite it to
only use WNE, if WNE is really in Sys6 whether MF is on or off. Thanks!

 -                                                                     -
 - Dave Martin - Geochemical & Environmental Research Group, Texas A&M -
 - DAVE@GERGA[GERGO,GERGI].TAMU.EDU - [e-mail] - AOL:DBM -
 -                                                                     -

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Mon, 20 Jul 1992 19:50:50 GMT

In article <[e-mail]> [e-mail] (Dave Martin) writes:
>I may go ahead and rewrite it to only use WNE, if WNE is really in Sys6
>whether MF is on or off.

_WaitNextEvent really and truly is always available under System 6 or newer.
Honestly.  Would I lie to you?  :-)

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Herb Poppe)
Date: 21 Jul 92 20:21:41 GMT
Organization: National Center for Atmospheric Research

In article <[e-mail]> [e-mail] (Dave
Martin) writes:

> What's the best way to implement a main loop which can get it's events
> either from WaitNextEvent or GetNextEvent (if WNE isn't available on
> that machine)?

> I was thinking along the lines of a boolean (hasWNE) and doing an:

>     IF (hasWNE AND WaitNextEvent(...)) OR
>               (NOT(hasWNE) AND GetNextEvent(...)) THEN... (Main Loop)

Note that both WaitNextEvent and GetNextEvent could be called depending on
how the compiler you use compiles AND and OR. The Pascal standard does not
require short-circuit evaluation of AND and OR. THINK Pascal (at least,
don't know about MPW) provides non-standard forms of AND and OR (I forget
the syntax) that always result in short-circuit evaluation.

Herb Poppe                 National Center for Atmospheric Research (NCAR)
[e-mail]       1850 Table Mesa Dr.
[phone]             Boulder, CO  80303

---------------------------

From: [e-mail] (Scott Bronson)
Subject: Gestalt glue is redundant!
Date: 8 Jul 92 10:59:11 GMT

I have some irks with THINK and MPW's using glue that emulates gestalt.
Isn't glue that emulates gestalt redundant? _Programming System 7_ says to
check to see if the _GestaltDispatch trap is defined before calling it.
So, because my code checks like the book says, the glue never gets
called, right?

Also, how can this glue be small and unobtrusive and still emulate
Gestalt?  Obviously, the glue can't emulate all selectors (as many
haven't even been thought of yet) so which ones does the glue take
care of?  How can we be certain that this glue won't break on a future
Macintosh system (or emulator)?

Is there any way for me to prevent this Gestalt glue from being
included in my application?  Also, is the source to this glue lying
around anywhere (so I can see what it takes care of and how, so I
can quell my fears about using it)?

Thanks in advance!

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Wed, 8 Jul 1992 13:27:01 GMT

In article <scott.710593151@mcl> [e-mail] (Scott Bronson) writes:
>I have some irks with THINK and MPW's using glue that emulates gestalt.
>Isn't glue that emulates gestalt redundant? _Programming System 7_ says to
>check to see if the _GestaltDispatch trap is defined before calling it.
>So, because my code checks like the book says, the glue never gets
>called, right?

Yes. Don't check, then :-)

>Also, how can this glue be small and unobtrusive and still emulate
>Gestalt?  Obviously, the glue can't emulate all selectors (as many
>haven't even been thought of yet) so which ones does the glue take
>care of?  How can we be certain that this glue won't break on a future
>Macintosh system (or emulator)?

The Gestalt glue emulates all selectors that provide information that could
have been obtained by calling SysEnvirons (Someone kick me if I'm wrong). The
glue won't break on a future Mac system, as future Mac systems will have the
_Gestalt trap.

>Is there any way for me to prevent this Gestalt glue from being
>included in my application?

#define SystemSevenOrLater in MPW.

>Also, is the source to this glue lying
>around anywhere (so I can see what it takes care of and how, so I
>can quell my fears about using it)?

Again in MPW: DumpObj -m GESTALT {Libraries}Runtime.o

Void where prohibited by law.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
 "You must have picked up that copy of Scarlett instead of Inside Mac
  when you tried to find the right call..." -- Keith Rollin

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 8 Jul 1992 13:08:04 GMT

[e-mail] (Scott Bronson) writes:
>Isn't glue that emulates gestalt redundant? _Programming System 7_ says to
>check to see if the _GestaltDispatch trap is defined before calling it.
>So, because my code checks like the book says, the glue never gets
>called, right?

Right.  Don't bother checking, let the compiler do the work for you.

>Also, how can this glue be small and unobtrusive and still emulate
>Gestalt?  Obviously, the glue can't emulate all selectors (as many
>haven't even been thought of yet) so which ones does the glue take
>care of?  How can we be certain that this glue won't break on a future
>Macintosh system (or emulator)?

Gestalt is set up so that older things return 0 and newer things return 1.
I presume the glue just returns 0 in cases where it "doesn't know."

>Is there any way for me to prevent this Gestalt glue from being
>included in my application?

Apart from not calling Gestalt...no, I don't think so.

>Also, is the source to this glue lying
>around anywhere (so I can see what it takes care of and how, so I
>can quell my fears about using it)?

It's with the source to the rest of MacTraps--us lowly users can't get
at it.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Life is a merry merry-go-round;  try to learn the secret I have found.
 Free and easy, easy and free.  That's the way it's gotta be.

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Wed, 8 Jul 1992 13:53:54 GMT

@mcl.ucsb.edu (Scott Bronson) writes:

   I have some irks with THINK and MPW's using glue that emulates gestalt.
   Isn't glue that emulates gestalt redundant? _Programming System 7_ says to
   check to see if the _GestaltDispatch trap is defined before calling it.
   So, because my code checks like the book says, the glue never gets
   called, right?

If you compile your headers using #define SystemSevenOrLater
(need to re-compile MacHeaders in Think) it will call Gestalt
directly instead of calling the glue.

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds
### and weird keyboard behaviour when you press the shift key repeatedly.

+++++++++++++++++++++++++++

From: [e-mail] (Charle Reiman)
Date: 8 Jul 92 16:32:33 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Scott Bronson) writes:

>I have some irks with THINK and MPW's using glue that emulates gestalt.
>Isn't glue that emulates gestalt redundant? _Programming System 7_ says to
>check to see if the _GestaltDispatch trap is defined before calling it.
>So, because my code checks like the book says, the glue never gets
>called, right?

Uh, no. If you call Gestalt(...) in C or pascal, then it goes thru the
glue.  The linker doesn't give a hooey what code comes before or after
a function call. If you invoke the _Gestalt trap in assembly, then
there is no glue and you are on your own.

>Also, how can this glue be small and unobtrusive and still emulate
>Gestalt?  Obviously, the glue can't emulate all selectors (as many
>haven't even been thought of yet) so which ones does the glue take
>care of?  How can we be certain that this glue won't break on a future
>Macintosh system (or emulator)?

It's Apple's job to make sure it works well. We're taking care of it.
Relax, leave the driving to us.

>Is there any way for me to prevent this Gestalt glue from being
>included in my application?  Also, is the source to this glue lying
>around anywhere (so I can see what it takes care of and how, so I
>can quell my fears about using it)?

If you hate our glue, use assembly and write your own. _Gestalt is the
trap name, nach.  Writing assembly glue is beyond the scope of this
posting.

As for source:

(in MPW)

DumpObj -m GESTALT "{Libraries}"Interface.o




Module:              Flags=$08=(Extern Code)  Module="GESTALT"(594) Segment="Main"(306)

Content:             Flags $08
Contents offset $0000 size $020E
00000000: 4E56 0000      'NV..'            LINK       A6,#$0000
00000004: 203C 0000 A89F ' <....'          MOVE.L     #$0000A89F,D0
0000000A: A746           '.F'              _GetTrapAddress  ,Sys,Immed          ; A746
0000000C: 2F08           '/.'              MOVE.L     A0,-(A7)

<...etc...>

If you're running Think C, you can probably get to the Gestalt glue by
ResEditing an application that calls Gestalt and disassembling it with
the code viewer. Simply search for invocations of the _Gestalt (A1AD)
trap.

Man, some people are just never satisfied. :-) For me, nothing beats
hot, fresh Gestalt, covered with lots of sticky glue.

- --
Charlie Reiman
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Date: 10 Jul 92 19:55:20 GMT
Organization: Instructional Technology Laboratory, University of Michigan

In article <scott.710593151@mcl> [e-mail] (Scott Bronson) writes:
>I have some irks with THINK and MPW's using glue that emulates gestalt.
>Isn't glue that emulates gestalt redundant? _Programming System 7_ says to
>check to see if the _GestaltDispatch trap is defined before calling it.
>So, because my code checks like the book says, the glue never gets
>called, right?
>
>Also, how can this glue be small and unobtrusive and still emulate
>Gestalt?  Obviously, the glue can't emulate all selectors (as many
>haven't even been thought of yet) so which ones does the glue take
>care of?

Find out!  Call them. If the glue can't determine the information needed
to answer a Gestalt question, it will return one of the Gestalt error codes
indicating this (one of the -500 codes).

>How can we be certain that this glue won't break on a future
>Macintosh system (or emulator)?
>

One must have faith, for without faith, one is nothing.

Seriously... if the compiler writers can't be trusted to write compatible
code, then who can? Presumably, Gestalt will always exist on a future system,
so the glue will simply call it. It shouldn't be necessary to figure out
an alternate method to determine the information wanted.

- --
..though I respect that a lot, I'd be fired if that were my job, after
killing Jason off and countless screaming argonauts... (They Might Be Giants)
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 11 Jul 92 01:33:39 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Charle Reiman) writes:
>
> [e-mail] (Scott Bronson) writes:
>
> >I have some irks with THINK and MPW's using glue that emulates gestalt.
> >Isn't glue that emulates gestalt redundant? _Programming System 7_ says to
> >check to see if the _GestaltDispatch trap is defined before calling it.
> >So, because my code checks like the book says, the glue never gets
> >called, right?
>
> Uh, no. If you call Gestalt(...) in C or pascal, then it goes thru the
> glue.  The linker doesn't give a hooey what code comes before or after
> a function call. If you invoke the _Gestalt trap in assembly, then
> there is no glue and you are on your own.
>
> >Also, how can this glue be small and unobtrusive and still emulate
> >Gestalt?  Obviously, the glue can't emulate all selectors (as many
> >haven't even been thought of yet) so which ones does the glue take
> >care of?  How can we be certain that this glue won't break on a future
> >Macintosh system (or emulator)?
>
> It's Apple's job to make sure it works well. We're taking care of it.
> Relax, leave the driving to us.
>
> >Is there any way for me to prevent this Gestalt glue from being
> >included in my application?  Also, is the source to this glue lying
> >around anywhere (so I can see what it takes care of and how, so I
> >can quell my fears about using it)?
>
> If you hate our glue, use assembly and write your own. _Gestalt is the
> trap name, nach.  Writing assembly glue is beyond the scope of this
> posting.

No no no.  If you don't want the Glue for Gestalt, then you don't have to
use it.  Take a look at the C interface for the trap. If you set the
- -d SystemSevenOrLater flag you will get _no_ glue at all.

But! the glue for Gestalt is pretty small, about 500 bytes the last time
I checked.  If you do set this flag, then you will have to check for
the trap being implemented, and always check for errors returned by Gestalt.


#if SystemSevenOrLater
#pragma parameter __D0 Gestalt(__D0,__A1)
pascal OSErr Gestalt(OSType selector,long *response)
 = {0xA1AD,0x2288};
#else
pascal OSErr Gestalt(OSType selector,long *response);
#endif

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | RAll opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc.S

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 11 Jul 92 01:33:25 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Charle Reiman) writes:
>
> [e-mail] (Scott Bronson) writes:
>
> >I have some irks with THINK and MPW's using glue that emulates gestalt.
> >Isn't glue that emulates gestalt redundant? _Programming System 7_ says to
> >check to see if the _GestaltDispatch trap is defined before calling it.
> >So, because my code checks like the book says, the glue never gets
> >called, right?
>
> Uh, no. If you call Gestalt(...) in C or pascal, then it goes thru the
> glue.  The linker doesn't give a hooey what code comes before or after
> a function call. If you invoke the _Gestalt trap in assembly, then
> there is no glue and you are on your own.
>
> >Also, how can this glue be small and unobtrusive and still emulate
> >Gestalt?  Obviously, the glue can't emulate all selectors (as many
> >haven't even been thought of yet) so which ones does the glue take
> >care of?  How can we be certain that this glue won't break on a future
> >Macintosh system (or emulator)?
>
> It's Apple's job to make sure it works well. We're taking care of it.
> Relax, leave the driving to us.
>
> >Is there any way for me to prevent this Gestalt glue from being
> >included in my application?  Also, is the source to this glue lying
> >around anywhere (so I can see what it takes care of and how, so I
> >can quell my fears about using it)?
>
> If you hate our glue, use assembly and write your own. _Gestalt is the
> trap name, nach.  Writing assembly glue is beyond the scope of this
> posting.

No no no.  If you don't want the Glue for Gestalt, then you don't have to
use it.  Take a look at the C interface for the trap. If you set the
- -d SystemSevenOrLater flag you will get _no_ glue at all.

But! the glue for Gestalt is pretty small, about 500 bytes the last time
I checked.  If you do set this flag, then you will have to check for
the trap being implemented, and always check for errors returned by Gestalt.


#if SystemSevenOrLater
#pragma parameter __D0 Gestalt(__D0,__A1)
pascal OSErr Gestalt(OSType selector,long *response)
 = {0xA1AD,0x2288};
#else
pascal OSErr Gestalt(OSType selector,long *response);
#endif

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | RAll opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc.S

+++++++++++++++++++++++++++

From: [e-mail] (Jerome Chan)
Date: 11 Jul 92 06:35:40 GMT
Organization: Alethea, The Twilight World!

In article <[e-mail]> Charle Reiman, [e-mail]
writes:
>If you're running Think C, you can probably get to the Gestalt glue by
[... Other Stuff Deleted ...]

  Where is this Gestalt Glue documented for Think C? You mean I spent the
entire night digging through Inside Mac V and VI,trying to code for
Gestalt and SysEnvirons for nothing? :)

  Eagerly awaiting replies.


- -Beware! NewBie Programmer at work-

+++++++++++++++++++++++++++

From: [e-mail] (James Preston)
Date: 15 Jul 92 00:41:18 GMT
Organization: Amdahl Corporation, Sunnyvale CA

[e-mail] (Jerome Chan) writes:

}In article <[e-mail]> Charle Reiman, [e-mail]
}writes:
}>If you're running Think C, you can probably get to the Gestalt glue by
}[... Other Stuff Deleted ...]

}  Where is this Gestalt Glue documented for Think C? You mean I spent the
}entire night digging through Inside Mac V and VI,trying to code for
}Gestalt and SysEnvirons for nothing? :)

Yup.  Just like I, apparently, typed in all the does-this-trap-exist code
from IM VI for nothing.

The glue is not documented anywhere in the THINK C documentation.  Symantec
makes great compilers, but the completeness of their documentation is sadly
lacking.

- --James Preston


+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Organization: GCC Technologies
Date: Wed, 15 Jul 1992 01:01:07 GMT

In article <[e-mail]> [e-mail] writes:

>The glue is not documented anywhere in the THINK C documentation.  Symantec
>makes great compilers, but the completeness of their documentation is sadly
>lacking.

In defense of the guys who wrote the doc, it's not their responsibility (nor
is it Symantec's) to document the Macintosh toolbox interface, particularly
since it's a moving target. The Gestalt glue (and the rest of the components
of MacTraps and MacTraps2) are supplied by Apple.

It's also not their responsibility to teach people how to program the Macintosh
or how to program in C; there are reference materials already extant that
do a very complete job at both tasks, including, but not limited to,
Kernighan & Ritchie's "The C Programming Language" and Apple Computer's
"Inside Macintosh" (along with associated technical notes and other related
materials).

R.



- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Joshua Rabinowitz-Summer-91)
Organization: NASA/ARC Information Sciences Division
Date: Thu, 16 Jul 1992 01:57:01 GMT

No, I agree, the think C manuals, while very good, could use to be
a little better, especially in the area of cross - referencing.

- --
- ----------------------------------
#include <std/disclaimer.h>     Josh Rabinowitz, Mac TCL programmer
[e-mail]
"Why is it that we drive on parkways and park in driveways?" - self

+++++++++++++++++++++++++++

From: [e-mail] (James Preston)
Date: 20 Jul 92 20:43:57 GMT
Organization: Amdahl Corporation, Sunnyvale CA

[e-mail] (Rich Siegel) writes:

}In article <[e-mail]> [e-mail] writes:

}>The glue is not documented anywhere in the THINK C documentation.  Symantec
}>makes great compilers, but the completeness of their documentation is sadly
}>lacking.

}In defense of the guys who wrote the doc, it's not their responsibility (nor
}is it Symantec's) to document the Macintosh toolbox interface, particularly
}since it's a moving target. The Gestalt glue (and the rest of the components
}of MacTraps and MacTraps2) are supplied by Apple.

}It's also not their responsibility to teach people how to program the Macintosh
}or how to program in C; there are reference materials already extant that
}do a very complete job at both tasks, including, but not limited to,
}Kernighan & Ritchie's "The C Programming Language" and Apple Computer's
}"Inside Macintosh" (along with associated technical notes and other related
}materials).

Well, this is getting a little off topic, but since I feel strongly that
the THINK products' documentation is a very large blemish on otherwise
excellent products, I'd like to followup a little.

I disagree when you say that it is not the responsibility of the THINK C
documentation to talk about something like the Gestalt glue code.  In the
first place (and I'm sure I don't need to remind Rich of this), THINK C
is not just a C compiler, it is a Macintosh development environment.
Therefore, its documentation certainly should talk about the interface
between the application program and the Mac toolbox.  More importantly,
in this particular case, calling the glue code is something that the compiler
does _behind the programmer's back_.  It doesn't matter where that glue
code comes from, be it Apple or anywhere else; the point is that the code
generator does not see my call to Gestalt and emit a call to directly to
Gestalt.  It emits code to call the glue code.  I agree that it is a good
thing to do, but certainly any such behind the back calling must be
documented by the product that does so, which in this case is THINK C.

I don't see how something like this can be put in the category of "teaching"
Mac or C programming; what I'm saying is that the documentation left out
a feature _of the code generator_ (i.e. that it calls glue code rather than
the Gestalt routine directly), and I therefore ended up doing an hour or
so of unecessary work.

- --James Preston


+++++++++++++++++++++++++++

From: [e-mail] (Paul Frederick Snively)
Date: Mon, 20 Jul 92 21:53:28 PDT
Organization: The Portal System (TM)


+++++++++++++++++++++++++++

From: [e-mail] (Paul Frederick Snively)
Date: Mon, 20 Jul 92 21:56:46 PDT
Organization: The Portal System (TM)

[e-mail] (James Preston) writes:

>[e-mail] (Rich Siegel) writes:
>
>}In article <[e-mail]> [e-mail] writes:
>
>}>The glue is not documented anywhere in the THINK C documentation.  Symantec
>}>makes great compilers, but the completeness of their documentation is sadly
>}>lacking.
>
>}In defense of the guys who wrote the doc, it's not their responsibility (nor
>}is it Symantec's) to document the Macintosh toolbox interface, particularly
>}since it's a moving target. The Gestalt glue (and the rest of the components
>}of MacTraps and MacTraps2) are supplied by Apple.
>
>}It's also not their responsibility to teach people how to program the Macinto
sh
>}or how to program in C; there are reference materials already extant that
>}do a very complete job at both tasks, including, but not limited to,
>}Kernighan & Ritchie's "The C Programming Language" and Apple Computer's
>}"Inside Macintosh" (along with associated technical notes and other related
>}materials).
>
>Well, this is getting a little off topic, but since I feel strongly that
>the THINK products' documentation is a very large blemish on otherwise
>excellent products, I'd like to followup a little.
>
>I disagree when you say that it is not the responsibility of the THINK C
>documentation to talk about something like the Gestalt glue code.  In the
>first place (and I'm sure I don't need to remind Rich of this), THINK C
>is not just a C compiler, it is a Macintosh development environment.
>Therefore, its documentation certainly should talk about the interface
>between the application program and the Mac toolbox.

The THINK C documentation _does_ talk about the interface between the
application program and the Mac toolbox, to the extent that it documents
how to use #include files and libraries in your projects.  There is nothing
magical about the Toolbox/OS interface viz-a-viz interfacing to any other
kind of library that you have library/header files for.

>More importantly,
>in this particular case, calling the glue code is something that the compiler
>does _behind the programmer's back_.  It doesn't matter where that glue
>code comes from, be it Apple or anywhere else; the point is that the code
>generator does not see my call to Gestalt and emit a call to directly to
>Gestalt.  It emits code to call the glue code.  I agree that it is a good
>thing to do, but certainly any such behind the back calling must be
>documented by the product that does so, which in this case is THINK C.

I have to disagree.  As has been pointed out before, the interfaces and
libraries that the THINK products ship with are licensed from Apple and
are a moving target.  Not only is Symantec not under the obligation to
reiterate Apple documentation regarding Apple interfaces and libraries,
it would be, IMHO, irresponsible of them to do so, since maintaining
parallel versions of such documentation would be a herculean effort
replete with the potential for the most egregious sorts of errors to
occur.

>I don't see how something like this can be put in the category of "teaching"
>Mac or C programming; what I'm saying is that the documentation left out
>a feature _of the code generator_ (i.e. that it calls glue code rather than
>the Gestalt routine directly), and I therefore ended up doing an hour or
>so of unecessary work.

Your assertion that the inclusion of the Gestalt glue in your code is `a
feature _of the code generator_' is in error.  The Gestalt call is defined
in ":Mac #includes:Apple #includes:GestaltEqu.h" (from the THINK C folder)
and is conditionalized on whether the compiler variable SystemSevenOrLater is
defined or not.  If it is defined, then the trap is used, otherwise the
function declaration is left unresolved, in which case it's up to the linker
to cope with it.  Note that all of these machinations--#include files,
compiler variables, preprocessor directives, etc.--are documented in the
THINK C documentation.  Apple's particular use of these features in their
interfaces and libraries, however, are not, and this is what I claim is as
it should be.

>--James Preston

Paul Snively
Dissolute Wandering Hacker
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 21 Jul 92 17:40:05 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (James
Preston) writes:
>
> I disagree when you say that it is not the responsibility of the THINK C
> documentation to talk about something like the Gestalt glue code.  In the
> first place (and I'm sure I don't need to remind Rich of this), THINK C
> is not just a C compiler, it is a Macintosh development environment.
> Therefore, its documentation certainly should talk about the interface
> between the application program and the Mac toolbox.  More importantly,
> in this particular case, calling the glue code is something that the compiler
> does _behind the programmer's back._  It doesn't matter where that glue
> code comes from, be it Apple or anywhere else; the point is that the code
> generator does not see my call to Gestalt and emit a call to directly to
> Gestalt.  It emits code to call the glue code.  I agree that it is a good
> thing to do, but certainly any such behind the back calling must be
> documented by the product that does so, which in this case is THINK C.

I must agree with Paul in disagreeing with you here. First of all, this is
nothing new, and you never complained until now. There are many, many routines
that are glue routines that appear no differently that direct trap calls. Take a
look at Inside Mac. Any routine marked as Not In ROM is a glue routine.
Additionally, until MPW 3.1, almost every OS routine was also a glue routine in
order to convert from a register based convention into a stack based based
calling convention. (This has been now changed with the use of inline code and
#pragma parameter). Finally, there are several calls provided as glue for C
programmers that convert C strings into Pascal strings before calling the
ToolBox or OS.

Secondly, calling the Gestalt glue is definitely not an idiosyncracy of the code
generator. If anything, you've got it the wrong way around. In C, something with
the following form:

        myErr = Gestalt(selector, &result);

is a function call (or a macro, I suppose), and results in the compiler calling
a function linked with your application. Anything else, such as inserting a trap
number, is the exceptional case. The code generator is just doing what the
headers tell it to, and in the normal case, the headers tell the compiler to
generate a function call.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


---------------------------

End of C.S.M.P. Digest
**********************